Skip to content

Fix round rect with negative values#2303

Draft
JoKing-1999 wants to merge 2 commits into
pygame-community:mainfrom
JoKing-1999:round_rect
Draft

Fix round rect with negative values#2303
JoKing-1999 wants to merge 2 commits into
pygame-community:mainfrom
JoKing-1999:round_rect

Conversation

@JoKing-1999
Copy link
Copy Markdown
Member

Fix #2285.

During this I discovered drawing round rect and circle quadrant have another issue not related to this one, but that would require another PR.

@JoKing-1999 JoKing-1999 requested a review from a team as a code owner July 11, 2023 10:16
@yunline yunline added draw pygame.draw bugfix PR that fixes bug labels Jul 11, 2023
Copy link
Copy Markdown
Member

@ankith26 ankith26 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello, thanks for the PR.

As I'm not experienced in these parts of the docs, I'm stuggling to understand even the smallest diffs 😅

I left some questions as reviews

Comment thread src_c/draw.c
rect->h = -rect->h;
}
// Ignore negative values
radius = MAX(radius, 0);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of simply ignoring negative values here, we could raise an error if this is negative instead

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could be another solution indeed

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

silently clamping it to 0 vs raising an error

I'm not sure which is preferable when using the code. I tend to be against silent things. Make is explicit, not implicit.

Comment thread src_c/draw.c

if (width > rect->w / 2 || width > rect->h / 2) {
width = MAX(rect->w / 2, rect->h / 2);
width = 0;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how this change is helping fix the issue, it looks like it will change behaviour against what is documented

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't do much. I do it just because of this line

if (width == 0) { /* Filled rect */
Basically if width == 0, draw filled rect. With old width=MAX(...) you would still get filled rect, but it wouldn't go in
if (width == 0) { /* Filled rect */
but rather in
else {

Comment thread src_c/draw.c
if (!bottom_left)
bottom_left = radius;
if (bottom_right < 0)
if (!bottom_right)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand from the docs

if any of these values are 0, the corner should have no rounded, and if the value is negative (default) it should "inherit" radius. This fix seems to be breaking whatever is documented in my understand, correct me if I'm missing something

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait a second, you are probably right. Gonna check tomorrow.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

He is right. This way a border_top_right_radius radius of 0 would inherit the value of border_radius whereas before it would set that corner to have no rounding.

I could imagine this breaking usage if somebody used the popular GUI button pattern of three rounded corners (set via border_radius and one at right angles set with border_top_right_radius.

Copy link
Copy Markdown
Member

@MyreMylar MyreMylar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this needs more work to finish off.

@ankith26 ankith26 marked this pull request as draft December 12, 2023 10:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix PR that fixes bug draw pygame.draw

Projects

None yet

Development

Successfully merging this pull request may close these issues.

rounding corners with pg.draw.rect is broken with negative values

5 participants